home *** CD-ROM | disk | FTP | other *** search
/ Aminet 7 / Aminet 7 - August 1995.iso / Aminet / docs / misc / ConcNews.lha / news / amiga.system / comp.sys.amiga.programmer_25908_000004.msg < prev    next >
Encoding:
Internet Message Format  |  1994-11-27  |  3.2 KB
  1. Path: cs.chalmers.se!chalmers.se!sunic!uunet!ukma!cs.widener.edu!dsinc!bagate!cbmvax!jesup
  2. From: jesup@cbmvax.commodore.com (Randell Jesup)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Info about _real_ semantics of hard/softlinks in AmigaOS
  5. Keywords: softlinks hardlinks links
  6. Message-ID: <38985@cbmvax.commodore.com>
  7. Date: 6 Feb 93 00:49:54 GMT
  8. References: <1993Feb3.150820.18164@fy.chalmers.se>
  9. Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
  10. Organization: Commodore, West Chester, PA
  11. Lines: 64
  12.  
  13. lundgren@fy.chalmers.se (Lars Lundgren) writes:
  14. >I'd like to see someone with some knowledge explain
  15. >what hardlinks (and the rudimentary softlinks) are like
  16. >in the present AmigaOS. As an example, I give my impression
  17. >of the semantics of UNIX hardlinks:
  18.  
  19. >Do Amiga hardlinks break these rules? I got the impression
  20. >by testing the other day, that the following semantics rule:
  21. >
  22. >x When you do a link from a to b, all you do is create
  23. >  a copy 'b' of 'a', with just one little pecularity - it
  24. >  doesn't occupy any disk space until you change either
  25. >  'a' or 'b'...
  26.  
  27.     No.  They work like Unix hardlinks.  The one major difference is
  28. that Lock()ing b, then doing NameFromLock() will give a (assuming you made
  29. a hardlink from b to a).  We hope to eventually (not soon) remove this
  30. difference.  Modifying the data of a or b will change it for both, just like
  31. in Unix.
  32.  
  33.     The one problem you can have is that many editors save via: delete/
  34. create, or rename/create/delete.  Obviously these "break" the hardlink.  If
  35. they do an Open(...,MODE_NEWFILE), or use SetFileSize(fh,0,OFFSET_BEGINNING)
  36. before writing the new data, then there's no problem.
  37.  
  38. >With hardlinks, you can in fact change the contents of a file
  39. >without touching it. Will notification still work? Will I get
  40. >notified of changes to 'a' if I change 'b'?
  41.  
  42.     Notification _should_ work, but I'm not sure it's ever been tested,
  43. and I would actually expect some bugs given the lack of testing.  Notification
  44. is more likely to work on hardlinks in ram:, but still no guarantee.
  45.  
  46. >What about protection bits, file dates? Are they concidered
  47. >belonging  to the file name or to the data itself?
  48.  
  49.     The date should be shared.  The protection bits should be separate
  50. for each link.
  51.  
  52. >Internally, AmigaDOS seems to differ files and hardlinks to files.
  53. >If I delete the original file in this case, will the link auto-
  54. >magically be tranformed to have the status of a real file?
  55.  
  56.     Yes.
  57.  
  58. >Softlinks. I realize that they are broken, and that implementing them
  59. >will cause severe problems with a system with multiple filesystems
  60. >like the Amiga. But just _how_ broken are they right now?
  61.  
  62.     They don't work in ram:.  In the ROM fs, they work to some degree
  63. if you use absolute paths, though matchfirst/next and most dos commands can
  64. get confused trying to deal with them.
  65.  
  66. >And why can't I get softlinks to work when part of a longer path?
  67.  
  68.     Use absolute paths when setting them up.
  69.  
  70. -- 
  71. GNU Emacs is a LISP operating system disguised as a word processor.
  72.  - Doug Mohney, in comp.arch
  73.  
  74. Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
  75. jesup@cbmvax.commodore.com  BIX: rjesup  
  76. Disclaimer: Nothing I say is anything other than my personal opinion.